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Abstract.  The  seamless  integration  of  commercial-off-the-shelf  (COTS) 
components  offers  many  benefits  associated  with  reuse.  Even  with  suc¬ 
cessful  composite  applications,  unexpected  interoperability  conflicts  can 
arise  when  COTS  products  are  upgraded,  new  components  are  needed, 
and  the  application  requirements  change.  Recent  approaches  to  integra¬ 
tion  follow  pattern-based  design  principles  to  construct  integration  ar¬ 
chitecture  for  the  composite  application.  This  integration  architecture 
provides  a  design  perspective  for  addressing  the  problematic  interac¬ 
tions  among  components  within  the  application  environment.  However, 
little  attention  has  been  paid  to  the  evolvability  of  these  architectures 
and  their  embedded  functionality.  In  this  paper,  we  discuss  the  need 
for  design  traceability  based  on  the  history  of  interoperability  conflicts 
and  resolution  decisions  that  comprise  the  integration  architecture.  Ad¬ 
ditionally,  we  advocate  that  certain  functional  aspects  of  a  pattern  can 
be  pinpointed  to  resolve  a  conflict.  Combining  these  two  aspects  of  inte¬ 
gration  architecture  design,  we  illustrate  that  often  evolution  is  possible 
with  minimal  changes  to  the  integration  solution. 


1  Introduction 

Integration  of  software  components  is  a  well-accepted  approach  to  address  the 
various  issues  associated  with  in-house  development  of  complex  systems.  How¬ 
ever,  it  is  not  always  a  simple  process.  Both  industry  and  academia  are  devel¬ 
oping  techniques,  methodologies,  and  products  to  alleviate  the  problems  sur¬ 
rounding  building  composite  applications.  One  central  point  to  be  considered  is 
how  the  inclusion  of  COTS  products  impacts  interoperability.  There  is  no  doubt 
that  in  most  cases,  COTS  products  offer  well-tested,  vendor-supported  software 
that  would  be  burdensome  to  build  in-house.  Though  such  in-house  development 
is  performed  (often  because  a  product  won’t  integrate  properly),  it  can  signifi¬ 
cantly  increase  development  cost,  while  at  the  same  time  decreasing  reliability 
and  support. 

There  are  many  reasons  why  integration  is  difficult.  Most  have  to  do  with 
the  behavioral  expectations  of  the  component  and  its  application  environment. 
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Other  reasons  include  a  shortage  of  tools  to  aid  professionals  in  an  integra¬ 
tion  effort.  They  must  often  rely  on  instinct  instead  of  a  principled  approach 
to  build  composite  applications.  As  in  all  software  development,  there  may  be 
disagreement  as  to  what  requirements,  components,  or  middleware  choices  are 
malleable.  Misjudgment  of  requirements  can  lead  to  unexpected  behavior  or  the 
use  of  unacceptable  products. 

Middleware  products  are  being  heavily  marketed  as  complete  solutions  to  all 
integration  needs.  They  can  be  a  perfect  fit,  integrating  components  smoothly. 
In  other  cases,  however,  vendor  consultants  are  needed  to  train,  assist,  and/or 
configure  the  solution.  Overall,  there  is  still  a  great  deal  of  guesswork  and  com¬ 
plexity  in  implementing  middleware  as  it  is  usually  considered  after  a  failed 
integration  attempt.  Basic  principles  of  requirements  engineering  and  software 
design  must  be  diligently  followed  to  achieve  seamless  integration. 

In  general,  patterns  provide  an  implementation  approach  to  problems  in  the 
form  of  repeatable  solutions.  Architectural  and  design  patterns  have  been  de¬ 
fined  that  underlie  middleware  frameworks.  Some  issues  need  to  be  addressed 
within  patterns  to  facilitate  their  use  for  general  component  integration.  Many 
viable  patterns  are  not  identified  as  integration  patterns.  Those  that  are  often 
do  not  detail  the  interoperability  conflicts  that  they  resolve.  Patterns  also  do  not 
naturally  identify  closed  box  functionality,  like  COTS  products,  present  in  the 
implementation.  Thus,  there  is  a  lack  of  direction  in  pinpointing  patterns  that  are 
descriptive  enough  to  assist  in  the  implementation  of  a  composite  application. 

Given  that  integration  goes  smoothly,  evolution  can  generate  additional  com¬ 
ponent  integration  issues,  while,  at  the  same  time,  making  others  obsolete.  These 
problems  are  magnified  when  a  COTS  product  is  part  of  an  integrated  applica¬ 
tion.  In  fact,  COTS  products  are  especially  susceptible  to  evolution,  including 
radical  changes,  due  to  the  need  to  attain  and  keep  a  broad  customer  base. 

Integration  solutions  should  be  altered  minimally  for  the  continued  reuse 
benefits.  To  do  this,  it  is  necessary  to  know  how  and  why  an  existing  integra¬ 
tion  solution  is  impacted  by  evolution  in  order  to  design  it  more  robustly.  This 
requires  an  understanding  of  why  a  pattern  is  use,  how  it  can  change  and  its 
effect  on  integration. 

In  this  paper,  we  use  the  history  of  interoperability  conflicts  and  resolution 
decisions  that  comprise  the  integration  architecture  as  a  basis  for  understanding 
the  design.  We  advocate  that  certain  aspects  of  a  pattern  can  be  pinpointed 
to  resolve  a  conflict.  Combining  these  two  aspects  of  integration  architecture 
design,  we  illustrate  that  often  evolution  is  possible  with  minimal  changes  to  the 
integration  solution. 

2  Background 

Maintaining  a  high-level  of  abstraction  at  which  to  relate  a  system  design  re¬ 
mains  the  basis  for  describing  an  architecture  for  software.  Through  software 
architecture  a  system’s  computational  elements,  their  interactions,  and  struc¬ 
tural  constraints  can  be  expressed  at  a  high,  yet  meaningful,  level  of  abstraction 
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(T].  Conceptual  system  issues  can  then  be  explained,  discussed  and  modeled 
without  becoming  entangled  in  implementation  and  deployment  details.  Char¬ 
acteristics  defined  with  respect  to  architectural  styles  include  those  that  describe 
the  various  types  of  components  and  connectors,  data  issues,  control  issues,  and 
control/data  interaction  issues  [21314]. 

Connectors  have  become  increasingly  important  in  software  architecture 
analysis,  forming  the  basis  for  component  connection  mm-  Explicit  descrip¬ 
tions  of  connectors  are  desirable  as  these  can  allow  for  design  choices  among 
and  analysis  of  existing  interaction  schemes,  along  with  the  specification  of  new 
connectors.  This  effort  can  allow  designers  the  flexibility  to  choose  the  correct 
interoperability  schemes  in  an  integrated  application. 

Architectures  and  patterns  that  form  middleware  frameworks  provide  guid¬ 
ance  to  “in-house”  integration  efforts.  Common  patterns  considered  as  integra¬ 
tion  patterns  are  the  Proxy  ms  and  Broker  that  afford  clients  and  servers  loca¬ 
tion  transparency,  plug  and  play  mobility,  and  portability  psnu.  Recent  inte¬ 
gration  patterns,  including  the  Wrapper-Facade,  Component  Configurator,  and 
the  Interceptor,  represent  repeatable  solutions  to  particular  integration  prob¬ 
lems  H21-  Enterprise  Application  Integration  patterns,  such  as  the  Integration 
Mediator  m  focus  on  integrating  enterprise  application  components.  These 
patterns  provide  functionality  such  as  interface  unification/reusability,  location 
transparency /negotiation,  and  decoupling. 

The  most  salient  point  to  be  made  concerning  integration  patterns  is  their 
lack  of  connection  between  the  interoperability  problems  requiring  the  use  of  the 
pattern  and  the  reason  the  pattern  resolves  those  problems.  As  more  patterns  are 
defined  and  their  complexity  increases,  at  stake  becomes  the  understandability  of 
the  integration  pattern  and  the  history  of  decisions  for  its  use.  In  short,  in  their 
current  state,  patterns  do  not  focus  on  issues  of  integration  solution  evolution. 

The  evolutionary  properties  of  components  can  be  captured  using  principles 
of  software  architecture.  One  goal  is  to  find  an  architecture  to  which  other  archi¬ 
tectures  can  transition  easily  PQ.  Though  architecture  migration  is  a  plausible 
solution,  it  is  not  always  feasible  for  all  systems,  especially  COTS  products  where 
many  properties  are  hidden.  In  a  similar  vein,  researchers  examine  constraints 
on  reconfiguring  architectures  to  assess  their  response  to  evolution  [15] .  This  il¬ 
lustrates  that  certain  properties  of  components  and  connectors  lessen  the  impact 
of  change  [I|j].  Certain  architecture  description  languages  support  architecture- 
based  evolution  through  the  changes  in  topology  [16| ,  optionality  [17] ,  and  vari¬ 
ability  (l8j. 

Analysis  methods  exist  to  assess  the  evolvability  and  reusability  of  a  compo¬ 
nent  architecture.  One  method  employs  a  framework  and  a  set  of  architectural 
views  m-  The  architectural  views  include  information  gathered  during  vari¬ 
ous  system  lifecycles  as  well  as  stakeholder  requirements.  Our  research  relies  on 
static  property  analysis  methods  to  evaluate  characteristics  of  the  architecture 
in  an  effort  to  identify  potential  interoperability  problems  [20121]. 
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3  Fundamentals  for  Understanding  Integration  Solution 
Design 

Collidescope  is  a  prototype  assessment  tool  to  provide  developers  with  a  means 
for  evaluating  integration  solution  design  decisions  [22).  The  ultimate  goal  is  to 
provide  the  developer  with  a  visible  link  between  interoperability  problems,  their 
causes,  and  their  solutions.  Collidescope  currently  implements  the  foundational 
underpinnings  needed  to  determine  potential  problematic  architecture  interac¬ 
tions  (PAIs).  PAIs  are  defined  as  interoperability  conflicts  that  are  predicted 
through  the  comparison  of  relevant  architecture  interaction  characteristics  and 
require  intervention  via  external  services  for  their  resolution  m-  Utilizing  broad, 
but  descriptive,  architectural  characteristics  of  the  component  systems  provides 
dual  benefits.  They  aid  discovery  of  PAIs  and  the  assessment  of  inevitable  future 
conflicts  brought  on  by  evolution  m  In  fact,  Collidescope  does  not  require  all 
component  characteristics  to  have  values.  It  can  work  with  only  a  partial  set. 
This  feature  is  very  important  because  little  information  may  be  known  about  a 
COTS  product,  especially  one  with  which  a  developer  has  had  little  experience. 
Of  course,  some  potential  PAIs  may  be  missed. 

Figure  1  depicts  two  linked  components,  Alpha  and  Beta,  in  a  composite 
application.  Control  structure,  the  structure  that  governs  the  execution  in  the 
system,  is  identified  for  each  of  the  components.  Alpha  has  a  concurrent  con¬ 
trol  structure,  while  Beta’s  is  single-threaded.  The  application  has  values  for 
many  of  the  same  characteristics  as  the  component  with  a  different  granularity. 
For  instance,  the  control  structure  of  the  application  governs  how  the  compo¬ 
nents  coordinate  their  execution.  We  will  return  to  application  characteristics 
in  Sect.  4. 


Fig.  1.  Architecture  Characteristics  with  Values  for  Control  Structure 
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As  a  first  pass  analysis,  Collidescope  detects  thirteen  PAIs  in  one  of  three 
categories.  These  categories  represent  distinct  issues  that  arise  in  component 
communication:  expectations  for  data  transfer,  expectations  for  control  transfer, 
and  how  interaction  between  components  is  initialized. 

Two  types  of  static  analysis  are  performed  m-  The  first  is  component- 
component  analysis  in  which  component  characteristic  values  are  compared. 
For  application- component  analysis,  the  application  characteristics  are  com¬ 
pared  with  each  component.  Figure  2  displays  the  potential  PAIs  found  by  a 
component-component  analysis  using  Alpha  and  Beta.  In  addition,  we  intro¬ 
duce  an  application,  Omega,  for  application-component  analysis.  The  name  is 
in  bold.  The  characteristic  is  in  italics  followed  by  a  value.  The  number  (1-13) 
is  the  conflict  preceded  by  its  category. 

When  comparing  these  characteristics  it  becomes  apparent  that  communi¬ 
cation  between  concurrent  and  single-threaded  components  will  be  difficult  as 
single  threaded  components  expect  directed  control  transfer  and  block  upon  ini¬ 
tiation.  Concurrent  components,  on  the  other  hand,  run  despite  the  execution 
state  of  other  participating  components. 


Alpha 

Beta 

Control  Structure  |  Concurrent 

Control  Structure  |  Si  ngle  Thread 

4  | Control  Transfer  (Sequencing  multiple  control  transfers 

Omega 

Alpha 

Control  Structure  |  Single  Thread 

Control  Structure  |  Concurrent 

4  |Control  Transfer  |Sequencini 

g  multiple  control  transfers 

Omega 

Alpha 

Control  Topology  |  Hierarchical 

Control  Structure  |  Concurrent 

1  |control  Transfer  | Restricted  points  of  control  transfer 

Omega 

Alpha 

Data  Topology  |  Hierarchical 

Control  Structure  |  Concurrent 

5 

Data  Transfer 

Restricted  points  of  data  transfer 

10 

Data  Transfer 

Sequencing  multiple  data  transfers 

Fig.  2.  Problematic  Architecture  Interactions 


The  next  step  in  the  assessment  is  the  identification  of  integration  elements 
that  resolve  the  PAIs.  This  completes  the  design  path  from  an  identified  problem 
to  the  fundamental  solution.  We  model  the  basic  functionality  needed  for  inte¬ 
gration  as  three  integration  elements:  translator ,  controller,  and  extender  [241251. 
These  integration  elements  supplement  the  traditional  architecture  connectors. 

A  translator  has  some  basic  properties.  It  should  communicate  with  other 
components  independent  of  their  identities.  Input  must  have  a  uniform  structure 
that  is  known  by  the  translator’s  domain.  Third,  conversions  must  be  represented 
by  a  total  mathematical  relation  or  composition  of  relations  that  maps  the  input 
to  the  output.  Translators  are  particularly  necessary  in  heterogeneous,  COTS- 
based  integrations,  as  consistently  formatted  data  is  never  expected  between 
vendors. 
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Transaction  Mediator 
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SMTP 
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Fig.  3.  The  InfoTrade  System  Architecture 


A  controller  integration  element  coordinates  and  mediates  the  movement 
of  information  between  components  using  predefined  decision-making  processes. 
The  decisions  include  determining  what  data  to  pass,  from  which  component  to 
accept  data,  and  to  which  component  data  should  be  sent.  Multiple  decisions  can 
be  made  within  a  single  controller.  Decisions  can  be  based  upon  input  data,  input 
components,  output  components,  or  a  combination  of  data  and  components. 

An  extender  integration  element  adds  those  features  and  functionality  to  an 
integration  solution  to  further  adapt  it  to  the  application  environment,  embody¬ 
ing  those  behaviors  not  performed  by  a  translator  or  controller  (e.g.,  buffering, 
adding  call-backs,  opening  files,  and  performing  security  checks).  Because  of  the 
diverse  behavior  of  extenders,  each  distinct  action  is  modeled  independently. 

The  above  integration  elements  may  be  combined  with  each  other  and  with 
simple  connectors  (e.g.,  a  UNIX  pipe)  to  form  integration  architectures  as  needed 
to  resolve  specific  conflicts.  An  integration  architecture,  then,  is  defined  to  be 
the  software  architecture  description  of  a  solution  to  interoperability  problems 
between  at  least  two  interacting  component  systems  [TT12Bj.  An  integration  ar¬ 
chitecture  forms  the  foundation  of  design  patterns  and  off-the-shelf  (OTS)  mid¬ 
dleware. 

The  use  of  static,  relevant  architectural  characteristics,  standardized  con¬ 
flicts,  and  simple  integration  functions  to  resolve  conflicts  provides  the  history 
of  design  decisions.  Therefore,  when  evidence  changes,  it  points  directly  to  the 
resulting  functionality  that  is  affected. 

4  An  Evolving  Application 

In  this  section,  we  study  the  requirements  of  a  composite  application  called 
InfoTrade,  a  system  for  automated  trading  of  commodities,  like  oil  and  gas. 
The  drive  to  develop  such  an  application  comes  at  a  time  when  automated 
stock  trading  is  in  full  swing.  Yet,  commodities  trading  is  just  beginning  to 
be  automated.  Many  of  the  needed  independent  software  components  (some 
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of  which  are  COTS)  are  in  place  but  only  partial  automated  trading  is  being 
done.  Much  of  the  information  before  and  after  a  trade  is  entered  manually. 
Furthermore,  because  automated  trading  is  limited,  there  is  a  mix  of  old  and 
new  styles  of  information  and  flow  that  must  be  blended. 

The  Info  Trade  system  architecture  is  shown  in  Fig.  3.  The  participating  com¬ 
ponents  include  External  Market,  Risk,  Logistics,  and  Financial.  The  External 
Market  is  comprised  of  a  national  commodities  market  information  module,  a 
database  to  house  all  of  the  bid/ask  requests  put  to  the  market,  and  a  SMTP 
for  dynamic  messaging.  Risk  uses  a  history  of  Bid/ Ask  requests  to  assess  the 
financial  exposure  of  the  corporation.  Logistics  is  a  database  of  transportation 
(car,  boat,  plane,  etc.)  information,  including  specifications  and  statistics  associ¬ 
ated  with  transporting  commodities.  Financial  is  a  database  of  customer  billing 
information,  as  well  as,  corporate-wide  financial  information. 

Info  Trade  integrates  COTS  components  essential  to  the  execution  of  a  com¬ 
modities  trade  using  the  Transaction  Mediator  (Fig.  3)  -  an  implementation 
of  the  Integration  Mediator  architecture  Pi-  This  solution  accommodates  the 
different  component  data  formats  and  communication  methods.  Within  the  in¬ 
tegrated  application,  the  Transaction  Mediator  is  stateless,  needing  only  the 
current  Bid/Ask  request  to  perform  its  mediation.  Thus,  to  make  a  trade  in  this 
system,  the  user  places  a  bid,  which  is  routed  through  the  Transaction  Mediator. 
The  Intelligent  Router  coordinates  the  direction  of  the  Bid/ Ask  message.  Con¬ 
tent  Transformers  intercept  the  message  and  transform  it  to  a  format  for  their 
respective  components.  Risk  analysis  is  performed  only  on  a  weekly  basis  when 
the  market  is  closed  and  no  bids  are  being  placed.  The  Intelligent  Router  calls 
the  External  Market  to  request  the  current  store  of  Bid/Ask  requests,  sequenc¬ 
ing  any  concurrent  communications  such  as  a  SMTP  packet  being  sent.  It  then 
routes  these  records  to  Risk  for  financial  exposure  analysis.  During  communi¬ 
cations  to  Risk  and  External  Market,  a  unique  Content  Transformer  translates 
incoming/outgoing  requests  to  ensure  the  request  data  formats  are  correct. 

With  the  expansion  of  e-commerce  opportunities  for  service-oriented  corpo¬ 
rations,  more  companies  desire  an  automated  commodities  facility  with  real-time 
risk  analysis.  This  institutes  a  new  composite  application  requirement  causing 
the  application  architecture  characteristics  to  evolve. 

The  real-time  requirement  places  new  demands  on  the  Transaction  Mediator, 
as  it  must  retain  the  current  Bid/ Ask  request  to  arbitrate  the  concurrently  exe¬ 
cuting  trade  and  the  financial  exposure  calculation.  The  question  becomes  how 
can  the  integration  solution  now  meet  this  new  requirement?  One  alternative 
is  to  scrap  the  existing  implementation,  choosing  more  dynamic  integration  ar¬ 
chitectures  such  as  a  Broker.  Another  alternative  is  to  re-write  the  Transaction 
Mediator,  perhaps  transitioning  from  its  combined  Java  and  JMS  implementa¬ 
tion  to  one  utilizing  real-time  CORBA.  Both  of  these  choices  go  against  the 
reuse  ideals  that  led  to  the  original  integration. 

The  design  decisions  supported  by  our  methodology  (Sect.  3)  provides  a 
direct  link  from  the  application  requirements  to  the  integration  elements  that 
make  up  the  integration  solution.  This  fosters  evolution  by  providing  the  devel¬ 
oper  with  insight  into  which  parts  of  the  integration  solution  should  be  modified 
or  replaced,  as  well  as  insight  into  where  additional  pieces  of  functionality  are 
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needed.  The  assessment  method  does  not  discount  any  of  the  alternatives,  but 
helps  to  determine  which  -  a  new  design,  re-implementation,  or  evolution  -  is 
the  best  choice 

There  are  many  factors  that  contribute  to  the  formation  and,  subsequent, 
evolution  of  the  Info  Trade  integrated  application.  First,  it  is  important  to  look 
at  the  components  in  the  current  application.  As  these  are  COTS  systems,  lit¬ 
tle  is  known  of  their  internal  functionality.  Besides  their  obviously  dissimilar 
data  formats,  only  the  component-level  characteristic  control  structure  can  be 
discerned.  Refer  to  Alpha  and  Beta  in  Fig.  1  as  the  External  Market  and  Risk 
components,  respectively. 

For  InfoTrade  to  accommodate  real-time  risk  analysis,  the  application  itself 
must  be  characterized  differently.  Table  1  shows  how  this  change  affects  how  the 
application  will  be  newly  described.  The  component  values  remain  the  same. 


Table  1.  Evolving  Application  Characteristics 


Characteristic 

Original  Value 

Evolved  Value 

Control  Structure 

Single  -Thread 

Concurrent 

Control  Topology 

Hierarchical 

Arbitrary 

Data  Topology 

Hierarchical 

Arbitrary 

Synchronization 

Synchronous 

Asynchronous 

The  way  in  which  changing  application  characteristics  shape  the  current  in¬ 
tegration  can  be  seen  in  a  comparison  of  these  new  values  to  the  current  control 
structure  values  of  the  components.  Collidescope  detects  the  new  PAIs  shown  in 
Fig.  4. 


Gamma 

Beta 

Control  Structure  |  Concurrent 

Control  Structure  |  Single  Thread 

4  |Control  Transfer  |Sequencin< 

g  multiple  control  transfers 

Gamma 

Beta 

Data  T  opology  |  Arbitrary 

Control  Structure  |  Single  Thread 

3 

Control  T ransfer 

Inhibited  rendezvous 

5 

Data  T ransfer 

Restricted  points  of  data  transfer 

Gamma 

Beta 

Control  Topology  |  Arbitrary 

Control  Structure  |  Single  Thread 

1 

Control  T ransfer 

Restricted  points  of  control  transfer 

3 

Control  T ransfer 

Inhibited  rendezvous 

Gamma 

Alpha 

Control  Structure  |  Concurrent 

Control  Structure  |  Concurrent 

4  |Control  Transfer  |Sequencing  multiple  control  transfers 

Fig.  4.  The  PAIs  Resulting  from  the  Evolved  Application  Characteristics 
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The  stateless  Transaction  Mediator  (depicted  in  Fig.  3)  as  initially  imple¬ 
mented  only  embodies  translation  and  control.  In  the  new  application,  both  are 
still  needed.  However,  the  Transaction  Mediator  now  must  also  buffer  the  data 
being  processed  by  Risk  and  External  Market  in  order  to  calculate  financial  ex¬ 
posure  while  placing  a  bid.  Otherwise,  refusal  of  a  trade  by  Risk  will  result  in  an 
inhibited  rendezvous  as  that  refusal  cannot  be  correlated  with  the  actual  correct 
request  to  circumvent  the  acceptance  of  the  trade  by  External  Market.  The  PAIs 
in  Fig.  4  reflect  this  problem  as  well  as  additional  conflicts  that  the  Transaction 
Mediator  currently  handles.  Figure  5  shows  the  evolved  architecture. 

By  using  this  style  of  analysis,  a  developer  is  more  likely  to  ascertain  the 
distinctive  problems  that  are  caused  by  changing  characteristics.  Moreover,  a 
direct  and  minimal  resolution  may  be  achieved. 


Application  Server 


Fig.  5.  The  New  Architecture  of  InfoTrade 


5  Conclusions 

Little  attention  has  been  paid  to  the  evolvability  of  these  architectures  and 
their  embedded  functionality.  In  this  paper,  we  show  how  design  choices  rely  on 
the  history  of  interoperability  conflicts  and  resolution  decisions  that  comprise 
the  integration  architecture.  Additionally,  we  advocate  that  certain  functional 
aspects  of  a  pattern  can  be  pinpointed  to  resolve  a  conflict.  Combining  these 
two  facets  of  integration  architecture  design,  we  illustrate  that  often  evolution 
is  possible  with  minimal  changes  to  the  integration  solution. 

The  approach  we  advocate  has  both  advantages  and  limitations.  The  assess¬ 
ment,  though  a  first-pass,  is  at  a  high-level  of  abstraction,  and  forms  a  reliable 
history  of  design  information.  In  turn,  the  history  is  easily  maintainable.  Given 
the  high-level  of  abstraction  present  in  the  assessment,  evolutionary  impacts  are 
relatively  easy  to  determine.  However,  the  abstraction  level  restricts  the  depth  of 
the  assessment,  as  exact  implementation  details  are  not  provided.  Furthermore, 
we  have  not  yet  proven  the  analysis  is  scalable  to  either  applications  comprised  of 
a  large  number  of  components  or  applications  with  diverse  middleware  products 
in  use.  We  reserve  these  findings  for  future  work. 
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